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Method, svstei" ^^'^'^ fo*^ ranting and controlling packet data flow 

The present invention relates genetaUy to telecommunication systems. In particular Ihe 
invention concerns routing and coiitrolling the flow of packet data transmissions m a 
mobile netwoik. 

3GPP (3"^ Generation Partnership Project) has recently pubUshed a specification for 
the 3GPP system comprising either UTRAN (UMTS Terrestrial Radio Access 
Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access network. 
The specification defines a new broadcasttoulticast service titled MBMS (Multimedia 
Broadcast/Multicast Service) [1]. MBMS basic arcWtectuie is illustrated in figure 1 
wherein CBC (Cell Broadcast Centre) 102, CSE (Camel Service Environment) 108, 
OSA/SCS (Open Service Access) 112 and related reference points can be considered 
as optional functionalities. Accordingly, mandatory conquments for realizmg a MBMS 
service are described next in refierence to [2]. 

The SGSN (Serving GPRS Support Node) 120 executes user specific service control 
fimctions, concentiates individual users of tiie same MBMS service into a single 
MBMS service and maintains a single connection witii the source of die MBMS data. 
Hie SGSN 120 may also authenticate users and antiiorise die usage of services based 
on subscription data fixim the HLR (Home Location Register) 106. The GGSN 
(Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS Tunneling 
Protocol) timnels fiom tiie SGSN 120 and links these tunnels via IP (fatemet Protocol) 
multicast wifli tiie MBMS data source. The BM-SC (Broadcast/Multicast Service 
CeaHe) 110 is an MBMS data source. The architecture also accepts other MBMS 
Ittoadcast/multicast data sources and internal data sources 104 may directiy provide 
their data. Data deUvery by external sources 126 is controUed by Border Gateways 
(BG) 124 which may allow for example data fiwrn single addresses and ports to pass 
into die PLMN (Public Land Mobfle Netwoik) for deKvety by an MBMS service. 
MBMS data inay be scheduled in flie BM-SC 110, for example, to be tonsmitted to the 
user every hour. It offers interfeces which can be utilized by a content provider 104, 
114 in requesting data delivery to users. The BM-SC 1 10 may autiiorise and charge the 
content provider 104, 114. The Gmb reference point between BM-SC 110 and GGSN 
122 enables the BM-SC 110 to exchange MBMS service control infoimalion wifli the 
GGSN 122. The Gmb reference point exists in order to carry tiie MBMS service 
information but it may not always be necessary to use the Gmb for each service. 



wo 2004/036837 



PCT/Fn003/000763 



15 



MBMS service can be deUvered to user equipment (UE) 116. 128 such as a mobile 
terminal over GERAN 130 orUTRAN 118. 

The architecture assumes the use of IP multicast at the reference point Gi. ^^^^S 
date source has only one comiection to the IP backbone. The reference pomt from the 
^iT^^der to the BM-SC 110 is currently not standardized as it mrght become 
t^conSex or restrictive for service creatior. For example th. may a ^-^^ 
point between the BM-SC 110 and an authoring system, or the authonng ^'^^ 
Zy be distributed between bolh entities. Tho same architecmre P--^ 
broadcast services mainly by using the transport functions. user -«i«vxd,^SN 
functions are not required. Instead each individual broadcast service ts configured m 
the SGSN 120. 

the SGSN 120 may use CAMEL (Customised AppUcation for Mobile network 
Euhanced Logic) to handle pre-paid services, e.g. credit checking for on-line chargmg. 
The Cell Broadcast Centre (CBC) 102 may be used to amiounce MBMS services to ffie 
i^ers. The BM-SC UO may explott OSA-SCS 112 to interact ^^J^^^^'^^"^ 
the terminal spUt, MBMS shall be able to interoperate wifli an IP mulh^ chent 
software on the terminal: More detailed information about MBMS service 
20 activationto^lease models, data transfer, functionalities of network elements, ra(ho 
interface bearer set-up/release. QoS (Quality of Service), security issues etc. can be 
found in the references [1] and [2]. 

As depicted in figure 1. GERAN 130 can be comiected 1o the oore^ i^ 
25 throuXluorGbinterfi«:e.Iuinter&cecomu«tsfheGERAN130to3GSG^ 

nie protocols and tf» fbnctiooal spUt between Ae radio access networic md the erne 
netw^^ in that case «ie same for UTRAN 118 and GERAN 130. See figure 2 for 
Ae illustmtion of user plane protocol stack in lu mode. Packet Data Convergence 
Protocol (PDCP) m^s higher-level chaacteristics onto the chatactois^cs of the 

30 mderlying radio-mterfece protocols to prcmding protocol tran^^ 

layer p^tocols. GPRS T^effing Protocol ^ the user plane (GTP-U) tmmels user 
dia ^ween UERAN and the 3G SGSN, and between the GSNs ^-^^f^^ 
network. GTP encapsulates all PDP (Packet Data Protocol) PDUs (Protocol Date 
Unit). UDP/IP (User Datagram Protocol, Internet Protocol) are the backb^e network 

35 protocols used for routing user data and control signalling. The RLC J^o Lirfc 
Control) protocol provides logical link control over «ie radio interfece. TTiere may be 
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several simultaneous RJLC links per terminal. Medium Access Control (MAC) controls 
the access signalling (request and grant) procedures for fhe radio chamiel. 

Gb interfece on the other hand connects the GERAN 130 to 2G SGSN 120 and the 
functional spUt between the BSS 130 (Base Station System, -radio access network e.g. 
GERAN) and the SGSN 120 is different from the UTRAN/GERAN lu mode. For 
example, ciphering is done in the core network (SGSN). Also the protocol architecture 
illustrated in figure 3 being described more thoroughly later in the text and the 
procedures between the SGSN and the BSS differ from the In case. 

As flie MBMS standardization worik has so &r been mainly focused on the lu interface, 
the procedures presented in the architecture and functi<mal description [2] are 
apphcable only for UTRAN/GERAN lu mode. Therefore, new functionality is needed 
if MBMS service is introduced into GERAN Gb interfece. One specific problem is that 
with Gb interface there is no RAB (Radio Access Bearer) concept in the same way as 
in tbs lu interfece. Thus the procedures conespoading to ihc MBMS RAB setup, 
release etc. do not afpply to the Gb interface. The SGSN establishes RABs basically on 
demand when there exists data to be transferred to the users. 

An option for MBMS (broadcast) service activation and RAB set-iq) is presented as an 
illustration in figure 4 in reference to [2]. At a SGSN re-start or when a new MBMS 
broadcast service is set-up, see phase 402, the SGSN 120 requests a creation of an 
MBMS context and GTP tumiel on the GGSN 122 for each RNC/BSC (Radio Nctworic 
Controller, Base Static Controller) w^hin the service area. In phase 404 the GGSN 
122 joins flie relevant IP multicast to connect the BM-SC 110 if not connected alreatfy. 
In phase 410 the GGSN confirms the establishment of the MBMS context. In phase 
412 MBMS data is sent to the GGSN 122 and in phase 414 forwarded to the SGSN 
120 through all related Gn/Gp tunnels. In phases 416 and 418 a RAB (Radio Access 
Bearer) is created for each MBMS ocmtext by utilizing assigmnont request and 
response procedures. In phase 420 MBMS notification is sent to tBrminails bemg finally 
followed by tiie transmission of actual MBMS data in phases 422 and 424. In a 
corresponding multicast case (not shown), the terminal first transmits an Activate 
MBMS Context Request to the SGSN 120. The IP multicast address identifies tiie 
MBMS multicast service, which the terminal wants to join. The SGSN 120 validates 
tiie Activate MBMS Context Request The MBMS context(s) store ^ parametos of 
flie activated MBMS multicast service. If said terminal is the first one activating ftis 
specific MBMS multicast service on flie routing area, the SGSN 120 determines the 
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RNCs serving the routing area and requests for each the creation of an MBMS context 
on the GGSN 122 and the estabUshment of a GTP tunnel between the SGSN 120 and 
the GGSN 122. Later in connection with the RAB set-up, the SGSN 120 sends MBMS 
RAB Request (indicating e.g. QoS parameters) only to the RNCs serving the Routing 
5 Areas in which there are temiinals which have jomed the MBMS context 

In addition to arrant data delivery issues, also other aspects remain open in exploiting 
the Gb interface. For example, various applications must not interfere with each other 
when the BSS 130 schedules the data transfer over tiie air interface. Nonnally both the 
10 SGSN 120 and BSS 130 have data buffers for data transmission. If the data buffer in 
the BSS 130 fills up because of an overwhehning data flow by a certain MBMS 
service, the transmission of other services using the same data transmission buffer is 
also negatively affected (transmission delays etc). This is one issue that must be taken 
into account if MBMS is introduced to the GERAN A/Gb mode as currently expected. 

15 

An object of the present invention is to alleviate aforesaid deficiencies and provide an 
addressing mechanism for routing MBMS data over the Gb interface betwera the 
SGSN 120 and BSS 130. Additionally, a flow control mechanism is needed for MBMS 
services as the bitrate tiiey typically require may be relatively high and varying caushxg 

20 potential problems also for other traffic delivered by tiie BSS 130. The object is 
achieved by introducing a concept of MBMS specific packet flow context (PFC), 
called MBPFC (Multicast/Broadcast Packet Flow Context) hareinafter, to the Gb 
interface with functionalities parfly corresponding the ones MBMS RAB provides in 
the lu mode. The proposed concept thus allows reuse of some already-existing 

2S procedures and resolves certain Gb inter&ce specific problems. 

The tOTn **BSS" (Base Station System) refers to a ra^o access network, e.g. a 
GERAN, comprising at least one base station and radio network controller / base 
station controller. 

30 

The tenn "Gb** refers to an interfiace between the BSS and second-generation packet- 
switched cote network. 

A mefliod according to the invention for routing MBMS (Multicast/Broadcast 
35 Multimedia Service) service data from a first network entity to a second network entity 
is characterized in that tiie method has the steps of 
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-defining a packet flow identifier (PFI) associated to at least one MBMS service 
or a group of temunals, 

-creating a packet flow context (PFC) for said MBMS service or group of 
tenninals identified by said PFI, 

5 -transferring the MBMS service data over the Gb interface by utilizing said PFC. 

In anotiier aspect of the invention, a system comprising a Gb interface between a first 
and a second network entity, is characterized in that in order to route MBMS service 
data over said Gb interface said first and second network entities are arranged to 
negotiate a common packet flow identifier (PFT) for said MBMS service or a group of 
10 terminals and said second netwoik element is arranged to create a packet flow context 
(PFC) for said service or group of terminals. 

In a fiirther aspect of the invention, a device functionally connected to a Gb inter&ce, 
is characterized in that in order to route MBMS ; (Multicast/Broadcast Multimedia 
Service) service data over the Gb interface it is arranged to define a packet flow 
15 identifier (PFI) associated to at least one MBMS service or a group of tenninals, to 
create a packet flow context (PFC) for said MBMS service or group of terminals 
idmtified by said packet flow identifier, and to transfer the MBMS service data over 
the Gb interface by utilizing said packet flow context 

Such a device may be e.g. a network element such as the SGSN operable in a second- 
20 graeration packet-switched core network and comprise standard processing (e.g. 
processor, nricro-controUer, signal processor, prbgranoimable logic), memory (e.g. one 
or more memory chips) and data transfer noeans (6.g. fixed data interfiice with 
controller) configured to execute the meOiod of the invention. 

The accompanying d^endent claims describe embodiments of the invention. 

25 In the following, the inventi<m is desoribed in more detail by reference to the attached 
drawings, wherein 

Fig. 1 is a block diagram of an MBMS capable system. 
Fig. 2 is a block diagram of the protocol architecture (user plane) in lu mode. 
30 Fig. 3 is a block diagram of the protocol architecture (usei/control plane) in 

A/Gb mode. 

Fig. 4 is a signalling chart disclosing one option for MBMS Broadcast service 
activation and RAB set-i^. 
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Fig. 5 A is a signalliBg chart disclosing the messaging applied in the creation of 
MBPFC. 

Fig. 5B is a signalling chart disclosing the messaging applied in fl»e deletion of 
MBPFC. 

Fig. 6 illustrates an option for the message structures ^Ued in the MBPFC 
creation and deletion* 

Fig. 7 presents the layers for controlling the flow of MBMS data routed over the 
Gb interface. 

Fig. 8 discloses a flow diagram of a method for routing and controllmg the flow 
of MBMS data in accordance with Ae invention. 

Figures lr4 were already covered in conjunction with the description of prior art The 
signalling chart in figure 4 presenting the MBMS service activation is feasible also in 
tins case what comes to phases 402-414 preceding the RAB set-iq>. 

The protocol stack of flie Gb interface as denoted in figure 3 contains layers tilled 
BiSSGP (BaseStation System GPRS Protocol) and Netwddc Service (NS). BSSGP 
controls the transfer of LLC (Logical Link Control) frames passed between an SGSN 
and a terminal across tiie Gb interface. Accordingly, the primary fimctions of the 
BSSGP include the provision by an SGSN 120 to a BSS 130 of radio related 
mfoimation used by the RLC/MAC function, flie provision by a BSS 130 to an SGSN 
120 of radio related information derived from tiie RLC/MAC function and the 
provision of fimctionality to enable two physically distinct nodes, an SGSN 120 and a 
BSS 130, to cpemte node management control fimctions. BSSGP Virtual Connections 
CBVC) provide communication paths between BSSGP entities. BVCs are identified by 
means of a BSSGP Virtual Connection Identifier (BVCI) which has end-to-end 
significance across the Gb interface. Each BVCI is unique between two peer Network 
Service Entities. The Network Service is the entity which actually provides netwodc 
service primitives allowing the transmission and reception of upper layer protocol data 
units between ihe BSS 130 and SGSN 120. The Network Service is based oh Ae 
Frame Relay (FR) connection between tiie BSS 130 and the SGSN 120, and may inulti- 
hop and traverse a network of Frame Relay switehing nodes. Each Network Service 
Entity is identified by means of a Network Service Entity Identifier (NSEI) which 
together witii tiie BVCI uniquely identifies a BSSGP Virtual Connection within an 
SGSN 120. The SGSN 120 needs not to be iqpdated ^wbgsa a new cfell (BVC/BVCO is 
added to the BSS (NSEQ 130. The NSEI is used by Ihe BSS 130 and the SGSN 120 to 
detennine the NS-VCs tiiat provide service to Ihe BVC. Logical link Coatxol (LLC) 
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offers a ciphered logical link being independent of Ae underlying radio interface 
protocols in order to allow introduction of alternative GPRS radio solutions with 
minimum changes to the NSS. KLC/hAAC contains two functiaas: The Radio Link 
Control function provides a Tadio^solution-dq)endent reliable link. The Medium 
5 Access Control function controls the access signalling (request and grant) procedures 
for the radio channel, and the mapping of LLC frames onto the physical channel. See 
the references [3], [4] and [5] for further details about GPRS protocol stacks, PDUs, 
BSS contexts, flow control as well as common GPRS attach/detach and PDP conte3ct 
activation/deactivation procedures. 

10 

The SGSN 120 can provide the BSS 130 with information related to ongoing user data 
transmission. The information related to one terminal is stored in a BSS context. The 
BSS 130 may contain BSS contexts for several terminals. A BSS context contains a 
number of BSS packet flow (PFC) contexts. A PFC is created with DOWNLOAD- 

15 BSS-PFC (optional), CREATE-BSS-PFC and CREATB-BSS-PFC-ACK PDUs as 
described in the reference [4]. A BSS packet flow context (PFC) is identified by a 
packet flow identifier (PFT)- There are four pre-defined packet flows identified by four 
reserved packet flow identifier values. One predefined packet flow is used for best- 
effort service, one for signalling, one for SMS (Short Message Service), and one for 

20 LCS (Location Services). The BSS 130 shall not negotiate BSS packet flow contexts 
for these pre-defined packet flows witii the SGSN 120. 

The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs sent 
by the SGSN 120 over the Gb interface to the BSS 130. There is a downlink buffer for 

25 each BVC in the BSS 130 identified by a BVCI. UNITDATA PDU contains an LLC 
PDU to be transmitted across the radio inter&ce to a terminal. The princ^le of the 
existing BSSGP flow conttol procedures is that the BSS 130 sends flow control 
parameters to the SGSN 120 thus allowing tihe SGSN 120 to locally conttol its 
transmission output in SGSN to BSS direction (flow control is used only in the 

30 downlink direction)* There are different levels of flow control: PFC, MS (Mobile 
Station; corresponding to a terminal) and BVC leveL The SGSN 120 shall always 
^ly BVC and MS flow control whereas PFC flow control is optional. The BSS 130 
controls flie flow of UNITDATA PDUs to its BVC buffers by indicating to the SGSN 
the maximum allowed througjiqiut for each BVC in a FLOW-CONTROL-BVG PDU. 

35 The BSS 130 controls the flow of UNITDAtA PDUs to the BjVC buffer of an 
individual terminal by indicatiiaig to the SGSN 120 the maximum allowed tinouglqiut 
for a certain TIXI (Tenq>Qrary Link Level Identity) with FLOW*CONTROL-MS 
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PDU, Additionally, FLOW-CONTROL-PFC PDU provides the SGSN 120 the flow 
control infonnation xegarding one or more PFC(s) of a given tenninal. The SGSN 120 
^>plies first PFC (if negotiated), then MS and finally BVC level flow controL If an 
LLC PDU to be included in a UNTTDATA PDU passes all applied levels of flow 
5 control it is forwarded to lower protocol layers to be transfeired to the BSS. 

Figures 5-7 disclose one option for enabling MBMS data routing and flow control 
between flie SGSN 120 and BSS 130 in accordance with the invention. In a general 
sense, a procedure partly congruent with the PFC concept described above can be 

10 appUed by creating a MBPFC for each MBMS service, a group of services or a group 
of terminals. From the SGSN's stanc^int said group of terminals may, for exanQ>le, 
belong to a same multicast group and reside behind a common BVC. The group, which 
typically contains at least two temiinals, may receive data firom a single source, e.g. an 
MBMS service, or fixnn multiple sources. Occuring randomly it is still i>ossible to have 

15 only one user (r<me teiminal) in the group though. !bi any case, the MBPFC is not 
logically connected to any individual tenninal/associated with any individual TLLI (or 
TMSI / P-TMSI). In multicast scenario the group for which flie MBPFC is logically 
connected may be identified by a specific ID (e.g. a ntmlticast ID). An MBMS specific 
PFI such as the multicast ID can also be sent to the terminals belonging to the multicast 

20 group for identifying the incoming MBMS flow. However, this may not be necessary 
as the identification can also be done in some other way (MBMS ID etc). The main use 
of an MBPFC is according to the inventicm to serve as an addressing mechanism 
between the SGSN 120 and the BSS 130 and fiualitate using flow contix>I in fiie Gb 
interface. In the BSS 130 ttie MBPFC is mapped to an appropri ate logical channel so 

25 that the announced MBMS service is sent on the channel indicated to usees in the 
service announcement procedure, wherein network broadcasts information e.g. about 
the fiiequency, time slot, and possibly TDMA firame when a particular service is 
scheduled over the radio inter&oe. 

30 The creation of an MBPFC can be executed as follows, see figure SA. The SGSN 120 
may initiate the procedure without any specific trigger fix>m the BSS 130 side. For 
exaniple, when tiie network establishes a new MBMS service or when the data is 
actually to be transferred the SGSN 120 toitiates the creation of an MBPFC relating to 
the service/multicast group. This can be done in conjuncticm with tiie service 

35 announcement or later on. The SGSN 120 requests for the creation of the MBPFC by 
sending a CREATE-MBPFC PDU 504 to the BSS 130 including a PFI to be used for 
the PFC identification. The BSS 130 (in the GERAN case the netwoik elements within 
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the BSS executing this task are the RNCs), responds with a CREATE-MBPFC-ACK 
PDU 508 or corresponding NACK if the MBPFC cannot be created. As the proposed 
method reminds of the one for creatmg a standard PFC with DOWNLOAEK-BSS^PFC 
(optional), CREATE-BSSrPFC and GREATE-BSS-PFC-ACK messages, the existing 

5 standard procedure can also be exploited in this MBMS specific caise, anyhow 
recalling that the essential difference is founded on a fact that the MBPFC is not 
logically connected to an individual terminal unlike the standard PFC. The network 
maps the PFC/PFI to a MBMS service/mutticast group and it is also possible, altiiough 
not advisable, to position all MBMS services into a single MBPFC. In that case 

10 different services cannot be treated ind^)end0ntiy and fliey may delay each oflier etc. 
The SGSN 120 and BSS 130 maintain entities, e.g. memory tables, of existing MBMS 
service/multicast group<->PFC/PFI mappinss in order to route and control the flow of 
the data to be tiansfeired and, in the BSS 130, to fiirther pass the received data over an 
appropriate (e.g. announced) logical channel to tra3niaal(s) either as a broadcast or 

15 PTM^oint-To-Multipoin1;e.g. multicast) transmission. 

Figure 6 discloses an option for tbe stcuctore of messages applied in the figure 5A. 
CREATB-MBPFC PDU 504 iiicludes fields for a message type identifier 602 e.g. a 
PDU type, PFI 604, ABQP 606 which is an Aggregate BSS QoS Profile (ABQP) 

20 defining the QoS agreed for the PFC (see Ihe reference [5]) and optional data 608 such 
as optional IDs or group (e.g. terminals belongmg to the same multicast groiq>) 
definitions/identifioation etc. CREATE-MBfPFC-ACK PDU 508 inchides 
conesponding fields for a type identifier 610, a PFI 612 and ABQP 614 that may be 
restricted by the BSS 130 based on its current status and capabilities. Conespondin^y, 

25 if NACK message is transmitted instead of ACK, a cause field can be included in the 
NACK to indicate tiie specific reason for refecting tiie MBPFC Creation as in a 
standard PFC case described in the reference [4]. 

MBPFC deletion can be executed respectively, see figure 5B. Tbs SGSN 120 requests 
30 the deletion when e.g. tiie service ^liveiy has been ceased by transmittmg a message 
DELETE-MBPFC 512 to tiie BSS 130 tiiat acknowledges tiie request witii DELETE- 
MBPFC ACK 516. It's also possible that tiie BSS 130 deletes the MBPFC for some 
reason (e.g. lack of data transfer, memory or processing resources) and then informs 
the SGSN 120 about the executed deletion witii a message, e.g. DELETE-MBPFC 
35 ACK 516. The message internals are not described here as tiicy are mostly in 
coofomiily wifli fiie ones presented for tiie creation of an MBPFC inclu£ng at least a 
message ID and TFI for Ihe identification purposes. 
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The SGSN 120 shall preferably perform flow control on each BVC, on each MBPFC 
and on some/all MBMS services as a whole, see figure 7. The flow control is 
performed first on each LLC-PDU (to be included in a UNTTDATA PDU) by an 
5 MBPFC specific flow control mechanism 702, then by an aggregate flow control 
mechanism 704 and finally by a BVC flow control mechanism 706. BVC flow control 
(typically corresponding a cell) parameters concerning hoUx standard PFCs as well as 
MBPFCs are received from the BSS 130 in a FLOW-CONTROL-BVC PDU described 
in the reference [4]. MBPFC flow control parameters can in prindple be received &om 

10 the BSS in a FLOW-CONTROL-PFC message as in a normal PFC case but the 
binding of the PFC with an individual terminal does not naturally apply. However, the 
BSS 130 may, for exan:q>le, estimate an average profile of terminals receiving the 
services and inform Ihe profile or relating parameters to the SGSN 120 for derivation 
of MBPFC specific flow control definitions. On the other hand, a set of rules may have 

15 been programmed in the BSS 130 indicating desired parameters (e.g. limit values for 
data leakage) for receiving services of varying type and based on fliat information, 
provide MBPFC specific parameters to the SGSN 120. As an third option, flie SGSN 
120 may define MBPFC flow control parameters based on some service related data or 
its current status (e.g. load). An entity called MBMS service block 708 may be created, 

20 under which there would be a number of MBPFCs carrying diJSerent MBMS services, 
to form an aggregate flow control level 704 comprismg at least one block 708 but one 
option is to perform only PFC and BVd flow control resfulting that the aggregate level 
704 in figure 7 does not exist Secondly, if only a single PFC is caceated for all MBMS 
services as mentioned earlier, tiie situation remains the same. The SGSN 120 may 

25 construct the MBMS service blocks 708 by, for example, dividing the MBMS services 
into a number of groups (linked to blocks) based cm the information about 
service/content type, content provider and service delivery requirements. This 
information, which cain also be utilized in the creation of MBPFC flow control 
definitions, may be received, fitmi a networic element Uke flie GGSN 122 or it can be 

30 derived internally either expUddy or inq>licidy fiom the MBMS data or relating 
ancillary information. 

A method applying the principle described hereinbefore is presented in figure 8. First, 
at a MBMS service start-itp 802 or, for cxaxnple, when the SGSN 120 has actually 
35 received data to be delivered to tenninals, a PFI is defined 804 for the service 
identification and a corresponding PFC (MBPFC) is created 806 in tiie BSS 130^ 
assigned by the SGSN 120. la practice, the order of phases 804 and 806 is not a 
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relevant issue as long as the MBPFC and PFI axe created as a result Next, the radio 
resources between the BSS and tenninals are reserved and set up in phase 808. This 
phase may include transnoitting of MBMS notifications: Flow control is performed 810 
before transferring Ae data over the Gb interface 812 from the SGSN 120 to the BSS 
5 130 and finally over the air interface 814 to the terminals. If more data appears to be 
delivered 816 the phases of flow control 810 and data transfer 812, 814 may be 
repeated. When no more data exists, for example, for a predetermined time period or 
the service is ranged down, the MBPFC may be deleted 818. It should be noted that 
the order of the aforementioned phases may be changed and some phases can even be 
10 altered or combined togeflier wi&out diverging from fhe concept of tibie invention. For 
example, phase 808 noiay be executed just before phase 814 if logical channels/radio 
resources are to be allocated in connection with actual data delivery. 

The scope of the invention is disclosed in the following independent claims. However, 
IS utilized messages, network elements, method and procedure steps etc may vary 
depCTiding on the current scenario, still converging to the basic ideas of the invention. 
Therefore, the invention is not strictly linoited to Ihe embodiments described above. 
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